In the 3GPP (3rd Generation Partnership Project), high-speed downlink data transfer in a WCDMA (Wideband Code-Division Multiple Access) mobile communication system is realized by HSDPA (High-Speed Downlink Packet Access) and high-speed uplink data transfer is realized by E-DCH (Enhanced Dedicated Channel).
High-speed downlink packet access is normally referred to as “HSDPA.” In HSDPA, a radio base station (hereinbelow referred to as “Node-B”) generates a radio physical channel referred to as an HS-DSCH (High-Speed Downlink Shared Channel) and loads downlink data or control signals on this HS-DSCH to transmit to a radio terminal (hereinbelow referred to as “UE (User Equipment)).”
In HSDPA, a plurality of UEs share the use of one or a plurality of codes, and HSDPA therefore has the advantages not only enabling the realization of high-speed data transfer but also of economizing radio code resources compared to a case in which one UE has exclusive use of one or a plurality of radio codes.
By means of HSDPA, data flow referred to as HS-DSCH MAC (Medium Access Control)-d flow is transferred in a network from a MAC-d entity in a radio base station controller (hereinbelow referred to as “RNC (Radio Network Controller)”) to a MAC-hs (Medium Access Control-high-speed) entity in Node-B. Here, data flow refers to the flow of data transferred over a prescribed path.
FIG. 1 shows an example of data transfer by HSDPA in a mobile communication system. In the example of FIG. 1, a serving RNC and a drift RNC are generated by the movement of UE. HS-DSCH MAC-d flow is then transferred from the MAC-d entity of the serving RNC via the drift RNC to the MAC-hs entity in Node-B that is under the control of the drift RNC.
In this case, the drift RNC only provides a transport bearer for the Iur interface and Iub interface for transfer as simple data flow without any awareness of the content of the HS-DSCH MAC-d flow.
FIG. 2 is a view for explaining an example of communication that uses HSDPA.
As shown in FIG. 2, one example of communication that uses HSDPA is the transfer of control signals of RRC (Radio Resource Control) protocol or a NAS(Non-Access Stratum) by an SRB (Signaling Radio Bearer; see 3GPP TS 25.331V6.8.0 (2005-12), Radio Resource Control (RRC) Protocol Specification, Release 6, pp. 40-41 (6.3 Signaling Radio Bearers)). NAS is control protocol between a UE and a CN (Core Network) and is not interpreted by an RNC.
A MAC-d entity on an RNC is made up from UE units. A MAC-hs entity on Node-B is constructed for each cell. A MAC-d entity multiplexes the SRB relating to the corresponding UE with the HS-DSCH MAC-d and transmits to the MAC-hs entity at Node-B. The MAC-hs entity multiplexes the HS-DSCH MAC-d flow on the HS-DSCH and transmits wirelessly.
By using HSDPA, an RNC can transmit control signals realized by HS-DSCH to a UE via Node-B. The advantage of this type of communication is that, because radio codes are shared among a plurality of UE, radio code resources can be economized.
In communication that uses this type of HSDPA, an RNC places SRB that is applied as input to a MAC-d entity in correspondence with the HS-DSCH MAC-d flow that is supplied from a MAC-d entity. For this purpose, the RNC saves information regarding the correspondence between an SRB ID and an HS-DSCH MAC-d flow ID. The RNC then uses this correspondence information to identify which SRB is to be transferred by which HS-DSCH MAC-d flow.
The MAC-hs entity at Node-B then identifies data that have been transferred in from the RNC by using the ID of the HS-DSCH MAC-d flow that transfers these data. For example, if the HS-DSCH MAC-d flow ID is a prescribed value, the MAC-hs entity can recognize the data transferred from the RNC as RRC protocol control signals.
In FIG. 2, for example, it is assumed that SRB1 is an RRC protocol control signal, SRB2 is an NAS call connection signal, and SRB3 is an NAS short message. A MAC-hs entity of Node-B can recognize the SRB by the HS-DSCH MAC-d flow ID, and in multiplex control, can preferentially multiplex the HS-DSCH MAC-d flow #1 for transferring SRB1 of RRC protocol having high importance in the HS-DSCH to the UE.
An E-DCH is also referred to as HSUPA (High-Speed Uplink Packet Access).
By means of E-DCH, data flow that is called E-DCH MAC-d flow in a network is transmitted from a MAC-e entity in Node-B to a MAC-es entity in the RNC. In the RNC, the MAC-es entity performs reordering of the E-DCH MAC-d flow and transmits the data flow that has undergone reordering to the MAC-d entity. Here, reordering is a process of viewing and rearranging the order of sequence numbers.
FIG. 3 shows data transfer by an E-DCH in a mobile communication system. In the example of FIG. 3, the serving RNC and drift RNC are generated by movement of the UE. A MAC-e entity in Node-B that is under the drift RNC then receives the data of the E-DCH from the UE, separates the E-DCH MAC-d flow from these data, and transfers the E-DCH MAC-d flow to the MAC-es entity in the serving RNC via the drift RNC. The MAC-es entity of the serving RNC performs reordering of the E-DCH MAC-d flow that has been received from the MAC-e entity in Node-B and then transmits to the MAC-d entity.
In this case as well, the drift RNC only provides a transport bearer to the Iur interface and Iub interface for transfer without awareness of the content of the E-DCH MAC-d flow.
FIG. 4 is a view for explaining an example of communication that uses an E-DCH.
As shown in FIG. 4, examples of communication that uses an E-DCH include cases of transferring RRC protocol or NAS control signals by an SRB.
The MAC-d entity on the RNC is made up from UE units as previously described. In addition, the MAC-e entity is also made up from UE units. The MAC-e entity of Node-B that has received E-DCH data from a UE separates into E-DCH MAC-d flow and transmits this to the MAC-es entity of the RNC. The MAC-es entity performs reordering of the E-DCH MAC-d flow and transmits to the MAC-d entity.
In this communication that uses an E-DCH, the RNC places in correspondence the E-DCH MAC-d flow that is applied as input to the MAC-es entity and the SRB supplied from the MAC-d entity. To this end, the RNC maintains information regarding the correspondence between SRB IDs and E-DCH MAC-d flow IDs.
By means of this correspondence information, the RNC then identifies which SRB is transferred in and by which E-DCH MAC-d flow.
In the state in which a serving RNC and drift RNC are generated as shown in FIG. 1 and FIG. 3, the data transfer path becomes long, and this gives rise to a delay in the transfer of data. In addition, a band of the circuit is allotted to transfer paths that have become longer than necessary, resulting in a state in which band resources are not efficiently used. To eliminate such states, relocation may be implemented to shorten the data transfer path and use resources efficiently (for example, refer to 3GPP TS23. 060 v6.11.0 (2005-12), General Packet Radio Service (GPRS) Service Description Stage 2, Release 6, pp. 77-94 (6.9.2.2 Serving RNC Relocation Procedures)).
FIG. 5 is a sequence chart showing the relocation operation in a mobile communication system. In the example of FIG. 5, as the initial state, the serving RNC and UE perform HSDPA and E-DCH communication via a drift RNC.
From this state, the serving RNC determines to implement relocation to, for example, optimize the path. In the relocation procedure, the serving RNC acts as the source RNC, and the drift RNC acts as the target RNC.
When the serving RNC (source RNC) transmits the message “Relocation Required” to the CN, a “Relocation Request” message is transmitted from the CN to the drift RNC (target RNC).
The drift RNC, having received the “Relocation Request” message, performs allocation of radio resources based on this message, and then returns a “Relocation Request Acknowledgement” message to the CN. The CN, having received the “Relocation Request Acknowledgement” message, transmits a “Relocation Command” message to the serving RNC.
Upon receiving the “Relocation Command” message from the CN, the serving RNC transmits a “Relocation Commit” message to the drift RNC. Upon receiving this “Relocation Commit” message, the drift RNC both transmits a “Relocation Detect” message to the CN and transmits a “UTRAN Mobility Information” message to the UE.
Upon receiving the “UTRAN Mobility Information” message, the UE returns a “UTRAN Mobility Information Response” message to the drift RNC, and the drift RNC thereupon returns a “Relocation Complete” message to the CN.
When relocation has been completed by the procedure of the above-described example, the drift RNC acts as the serving RNC and thus can communicate with the UE. Although an example has here been described in which relocation is implemented from a state in which both HSDPA and E-DCH are carried out, relocation can also be implemented from a state in which only one of the two is carried out.